updated to the new desktop build system

* This is already contained in the 5.15.27 kernel

pinctrl: sunxi: Use unique lockdep classes for IRQs

commit 896d1b8a36129c3f1378fbbafd7c394a877635b5 linux-5.15.y
commit bac129dbc6560dfeb634c03f0c08b78024e71915 upstream.

This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:

     ============================================
     WARNING: possible recursive locking detected
     5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
     --------------------------------------------
     init/307 is trying to acquire lock:
     c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

     but task is already holding lock:
     c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

     other info that might help us debug this:
      Possible unsafe locking scenario:

            CPU0
            ----
       lock(&irq_desc_lock_class);
       lock(&irq_desc_lock_class);

      *** DEADLOCK ***

      May be due to missing lock nesting notation

     4 locks held by init/307:
      #0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c
      #1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224
      #2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224
      #3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0

     stack backtrace:
     CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1
     Hardware name: Allwinner sun8i Family
      unwind_backtrace from show_stack+0x10/0x14
      show_stack from dump_stack_lvl+0x68/0x90
      dump_stack_lvl from __lock_acquire+0x1680/0x31a0
      __lock_acquire from lock_acquire+0x148/0x3dc
      lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c
      _raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0
      __irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c
      irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c
        [tail call from sunxi_pinctrl_irq_set_wake]
      irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4
      gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c
      gpio_keys_shutdown from device_shutdown+0x180/0x224
      device_shutdown from __do_sys_reboot+0x134/0x23c
      __do_sys_reboot from ret_fast_syscall+0x0/0x1c

    However, this can never deadlock because the upstream and downstream
    IRQs are never the same (nor do they even involve the same irqchip).

    Silence this erroneous lockdep splat by applying what appears to be the
    usual fix of moving the GPIO IRQs to separate lockdep classes.

    Fixes: a59c99d9eaf9 ("pinctrl: sunxi: Forward calls to irq_set_irq_wake")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

* This is already contained in the 5.16.13 kernel

pinctrl: sunxi: Use unique lockdep classes for IRQs

commit e221ef82d9f5e97bca61f7c25e2b58b04466de87 linux-5.16.y.
commit bac129dbc6560dfeb634c03f0c08b78024e71915 upstream.

This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:

============================================
WARNING: possible recursive locking detected
5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
--------------------------------------------
....